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Executive Summary 


The problems of corporate concentration and privacy on the Internet are inextricably 
linked. A new regime of interoperability can revitalize competition in the space, 
encourage innovation, and give users more agency over their data; it may also create 
new risks to user privacy and data security. This paper considers those risks and argues 
that they are outweighed by the benefits. New interoperability, done correctly, will not 
just foster competition, it can be a net benefit for user privacy rights. 


In section 2 we provide background. First, we outline how the competition crisis in tech 
intersects with EFF issues and explain how interoperability can help alleviate it. In “The 
Status Quo,” we describe how monopoly power has woven the surveillance business 
model into the fabric of the Internet, undermining the institutions that are supposed to 
protect users. Finally we introduce the “privacy paradox” —the apparent tension 
between new interoperability and user privacy—that frames this paper. 


In section 3, we present EFF’s proposals for interoperability policy. 


The first is “competitive compatibility” or ComCom: encouraging tinkerers and 
startups to interoperate with incumbent services without their permission. AComCom 
policy regime would dismantle the legal tools that corporations use to shut down 
interactions with their services that they don’t approve of. We propose better 
interpretations of, and reforms to, the Computer Fraud and Abuse Act (CFAA), Section 
1201 of the Digital Millennium Copyright Act (DMCA), and contract law pertaining to 
Terms of Service (ToS) and End User License Agreements (EULAs). 


The second proposal would require some companies to provide a baseline of 
interoperable access to their services. Data portability gives users the right to access and 
transfer their data from the companies that hold it. Back-end interoperability would 
require very large companies—those that dominate a particular market segment—to 
maintain interfaces that allow their users to interact fluidly with users on other services. 
Finally, delegability would require those large companies to build interfaces that allow 
third-party software to interact with their services on a user’s behalf. 


In section 4, we consider the new privacy risks that these policies may create and 
discuss how to mitigate them. 


Enabling competitive compatibility will help loosen dominant platforms’ control over 
how their services are used. This may leave the largest companies, to whom users 
entrust huge amounts of sensitive data, with fewer ways to shut down third-party 
actors that threaten user privacy. But big tech companies have never been good stewards 
of sensitive user data, and the laws we propose reforming have never been the right 
tools to protect it. Making it easier for new entrants to create privacy-preserving 
alternatives will pressure incumbents to do better, and allow users to migrate away 
when they don’t. 
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New interoperability rules will create new data flows, and remove some of the 
platforms’ discretion to decide how data is shared. But mandates can come with strings 
attached, in the form of legal obligations for informed consent and data minimization. 
As a result, data that flows across these new interfaces may be more legally protected 
than any data that the platforms have chosen to share in the past. 


In this paper, we imagine a world where interoperability and privacy go hand in hand, 
and abusive monopolists are not deputized to act as a private arm of the state. We can, 
and should, have both competition and privacy—and users should be able to enjoy the 
many other benefits of interoperability as well. 
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1. Introduction 


Internet market concentration is among the most important tech policy issues of our 
time. Over the past few years, a chorus of voices have begun calling for governments to 
intervene and rein in the tech giants’ power. However, there is less consensus on how 
exactly that should be done without causing new problems. 


This paper focuses on a set of proposals to increase interoperability between dominant 
companies and their smaller competitors. Interoperability fosters competition, and with 
competition comes more choice, and the chance to improve the quality of our online 
lives. An Internet with more competition will allow users to express themselves more 
freely and craft their online identities more deliberately. 


A crucial collateral benefit of interoperability and competition is the potential to 
improve user privacy. The privacy harms of the tech monopolies are extensive and 
well-documented. Competition gives users more power to decide how their information 
is shared and with whom, “vote with their feet” to move to different services when one 
is not sufficiently respecting their privacy, and chip away at the multifaceted 
surveillance networks that a handful of large companies deploy. Contrary to major 
platforms’ assurances, we cannot trust dominant companies to act as unilateral 
stewards of user privacy. To the extent that companies have to worry about users taking 
their business elsewhere (especially if users have low switching costs), companies will 
be pressured to be better stewards. 


However, interoperability could cause privacy harms. After all, more interoperability 
also means companies have new ways to share and collect personal information. This is 
an argument that the tech monopolies have themselves presented in defense of their 
behavior, and as part of a promise to behave better in the future. As Mark Zuckerberg has 
said to the U.S. Congress, “It's not enough to just connect people, we have to make sure 
that those connections are positive.” 


This presents a paradox: market concentration is central to the privacy crisis online, but 
the path to more competition creates new risks to privacy. One response could be to give 
up the fight, accept Facebook, Apple, Google et al. as the the best- placed defenders of 
personal privacy, and regulate them into that role on a presumed permanent basis, as 
the U.S. did to the Bell System for much of the 20th century. 


The goal of this paper is to present a better alternative, one that doesn’t deputize 
notoriously abusive monopolists to act as a private arm of the state. We can, and should, 
have both competition and privacy—and users should be able to enjoy the many other 
benefits of interoperability as well. We treat the risks to user safety and security with 
appropriate gravity, and argue for a user-centric interoperability policy regime that 
goes hand-in-hand with privacy. 


This whitepaper outlines some EFF proposals to promote competition and innovation 


through interoperability. It addresses the privacy risks of these proposals and discusses 
how we can mitigate them and shows why, despite some new risks, 
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interoperability-positive policy does not have to come at the cost of user privacy. Done 
right, interoperability can actually protect privacy by making it easier for users to 
control who has their data and how it is used. 


The paper is organized as follows: 


Section 2 gives background about competition, interoperability, and the tension between 
access and privacy. 


Section 3 presents EFF’s recommendations for policies that will promote and establish 
interoperability. 


Section 4 discusses privacy risks associated with these policies and proposes ways to 
mitigate those risks. 


Section 5 concludes. 


This whitepaper is not a comprehensive argument for interoperability per se. While we 
will give background on the competition crisis and why interoperability will help address 
it, we assume the reader agrees that more interoperability on the Internet is desirable, 
but has reservations about its effects on data privacy and security. Furthermore, this 
paper discusses the need for new privacy laws, but does not attempt to tackle the way 
privacy law should be written (see EFF’s previous work for more on that). This paper is 
specifically focused on mitigating the privacy and security issues associated with new 
interoperability policy. 


Although we discuss new legislation, news laws are not the only way to enact these 
policies. Some may fit best into a legislative agenda, while others could be given force as 
part of a package of litigation remedies. Better interpretations of existing law can also go 
a long way. Companies may even choose to voluntarily enter binding agreements to 
carry out these policies, possibly in order to stave off less desirable regulatory outcomes. 


This paper’s goal is to examine how things might change if we get the interoperability 
policy we want, so it’s important to note what we do not want. We are not advocating for 
unmoderated app stores; in fact, many app distribution systems (like the Chrome web 
store) can and should be moderated to protect user privacy. Instead, we are against 
anticompetitive use of moderation power, and against a moderated app store having a 
monopoly on software distribution. We do not want to remove computer crime laws 
altogether, and companies should be able to engineer their products the way they want. 
But the law should not help corporations control anything and everything that goes on 
within their products. 
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2. Background 


2.1. Interoperability and Competition 


EFF has long argued for the right of new market entrants—commercial and nonprofit, 
individual and institutional—to connect their products and services to existing ones, 
especially dominant ones. EFF has fought for the right to scrape information and the 
right to modify devices, the right to block trackers and reimplement APIs, the right to 
repair and the rights of reverse engineers. These are the building blocks of 


interoperability, which has a long history of breaking market strangleholds enjoyed by 
dominant companies. 


The market concentration crisis in tech has brought the need for interoperability into 
sharp focus. A number of factors have contributed to rapid, decisive centralization over 
the past two decades, with a handful of companies amassing unprecedented power 
across borders and industries. Those same factors make it highly unlikely that the tech 
sector will “fix itself” any time soon. 


For one, network effects give the biggest player in a market a powerful advantage over 
smaller, newer, and even superior competitors. Social media, in particular, has become a 
difficult market to break into as Facebook has made itself central to more aspects of its 
users’ lives. No one wants to join a new social media site if their friends aren’t on 
it—and all their friends are already on Facebook (or the Facebook- acquired properties 
Instagram or Whatsapp). Even in markets outside of traditional “social” media, the 
identity graphs controlled by a handful of giants make it easy for them to muscle out 
competitors in everything from online advertising to document collaboration. 


Of course, new companies do gain traction from time to time, usually by creating a new 
competitive sub- market: a chat app that delivers a better mobile experience like 
WhatsApp, or a dedicated visual image sharing tool, like Instagram. But for the better 
part of two decades, that hasn’t presented a real problem for incumbents. A lax and 
short-sighted merger review regime in the U.S. has allowed big companies to buy up 


competitors at an alarming rate. 


Better merger review will help, and unwinding problematic mergers from the past two 
decades will help more. But not all conglomerates are built through mergers, and 
structural separation is complicated and not guaranteed to fix the unique problems of 
concentration in tech. 


Interoperability is a key policy for a pro-competitive Internet. Interoperability 
undermines network effects that keep users locked into a conglomerate’s ecosystem. It 
removes barriers for new entrants by letting small players piggyback on the 
infrastructure developed by big ones. On the early Internet, the protocols everyone used 
to communicate (like TCP/IP and HTTP), were open and interoperable. If we can push 
the tech giants in that direction—towards being true platforms for others to work on top 
of, with, and around—then starting and growing a new co-operative or company will 
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get easier. Further, interoperability reduces the benefits of conglomeration, by making it 
harder for a big company to leverage one service to the benefit of its other holdings. 


As a goal, interoperability is great: it’s easy to imagine a world with lower switching 
costs for users, less protection for incumbents, and more innovation across the board. 
Interoperability is, in essence, data flow—successful policy will mean more personal 
data traveling more freely between servers around the world. 


Getting there is more difficult. Intervening in a fast-moving set of industries like today’s 
tech sector is never easy, and the interventions we propose need resources and finesse to 
execute correctly. 


2.2. The Status Quo 


Though they compete in different markets, most of the tech giants share at least one 
business model: surveillance. Technology conglomerates collect information about 
users from each of their dozens of smaller services, synthesize those data into profiles, 
and use those profiles to target ads. They also gather information about their 
competitors through app stores and third-party tracking beacons, then target them for 
acquisition or destruction. 


The excessive power of the tech giants has even distorted operating systems and 
browsers, so that “user agents” —the technical term for web browsers—work more as 
agents for trackers than for their users. It has warped the priorities of putatively 
user-centric standards bodies, where seats cost money, participation takes time, time 
costs more money, and the biggest players control the conversation. It has distorted 
government policy so that, year after year, privacy laws in the U.S. fail to advance 
despite overwhelming popular support. The power to achieve all this comes from the 
tactical weapons that usually correlate to monopoly power: first, they have the excessive 
profits (“monopoly rents”) that come from the absence of price competition; and 
second, they are in an industry that is so concentrated that all the major players can 
agree on how to mobilize that money to secure policies that protect their business. 


This practice has come to dominate the technology landscape so thoroughly that other 
dependent industries find themselves forcibly aligned with the surveillance model. News 
media companies will draft articles decrying tech surveillance, and then publish them on 
Web pages loaded with dozens of trackers. Politicians hold hearings on how these tools 
subvert democracy, even as they pay companies to help them target and track potential 
voters. Almost every potential champion for digital users ends up on the side of tech 
surveillance, and against user privacy. 


The sadly ironic corollary is that the development of consumer privacy laws in the U.S. 
has been stunted, so that Internet users' main bulwark against invasive conduct is the 
large tech companies themselves. For example, after Facebook faced the uproar 
regarding Cambridge Analytica’s misuse of data collected on its platform, its primary 
response was to lock down the data it had from third parties, while continuing to collect 
it for its own use. 
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The few laws that do protect U.S. users tend to focus on the harms of data sharing and 
sale, not of the rampant collection and internal processing that Google, Facebook, 
Amazon, and others perform. These laws are only useful in a world where no single 
company can document every part of a person’s life. 


2.3. The Privacy Paradox 


Breaking down the surveillance monopolies by promoting interoperability will help 
existing privacy laws function as they should. But there’s a catch: policies designed to 
increase interoperability may weaken the tools that companies currently use to protect 
their users. To enable tinkering and unsanctioned innovation, we’ll need to dismantle 
some of the legal weapons that companies brandish and wield against bad actors. In 
order to mandate baseline levels of interoperability, we’ll deprive companies of their 
absolute discretion over when they share data and with whom. To the extent that the 
tech companies are doing a good job shielding users from malicious third parties, users 
stand to lose some of that protection. 


However, one group of users stands to benefit from a reduction in the large companies’ 
power: those users whose interests are profoundly not served by the tech companies’ 
protections. These include Uyghurs who want to bypass Apple’s App Store monopoly in 
order to acquire a VPN that can shield them from the Chinese state; members of rare 
disease groups on Facebook who are at risk from Facebook’s own data mining; and 
Google users who attend protests and are at risk from having their location served up to 
law enforcement agencies with “reverse warrants” seeking retribution. 


The policies of large corporations are not—and never were—a good substitute for 
democratically created and enforced privacy protections. Increased 
interoperability—and decreased corporate power—opens policy space for real privacy 
remedies, ones that treat technology users as citizens with rights, not merely as 
consumers who can make purchase-decisions. 
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3. Policy Tools to Promote Interoperability 


Interoperability is everywhere. The kinds of interoperability we intend to promote—new 
stable interfaces to large platforms via mandates, and new competitive compatibility 
through better law—should both look familiar. 


Many companies already invite interoperability for a variety of purposes, from allowing 
integration with other services to fostering secondary application marketplaces. Large 
platforms especially tend to offer powerful application programming interfaces (APIs) 
that give third-party developers access to features of their products. The interfaces 
created under new mandates will likely look and function like supercharged versions of 
the interfaces companies already choose to expose. 


Likewise, competitive compatibility has long been practiced by ambitious young 
companies and curious independent developers alike. Gopher, the precursor to the 


modern Web browser, was a grand exercise in scrounging for information across the 
early Net. Financial aggregators like Mint started out by scraping data from bank 
websites on their users’ behalf. And in modern browsers, Web extensions like ad- and 


tracker-blockers help users experience the Web on their own terms—against the best 
efforts of advertisers. 


Policymakers can foster interoperability in two ways. First, we should help enable 
competitive compatibility (ComCom) by neutralizing the legal weapons that big 
companies use to lock down use of their products, which would pave the way for 
competitors to tinker and extend without fear of legal reprisal. Second, we support new 
interoperability mandates—data portability, back-end interoperability, and 
delegability—to guarantee accessible tools for interoperation. 


Competitive compatibility means that competitors can interoperate with bigger services 
and platforms without having to negotiate with them, ask their permission, or risk 
breaking a number of computer crime and intellectual property laws. Interoperability 
mandates go further to make that interoperability usable, stable, and accessible for 
users: data portability would make it easy for users to move from one platform to 
another; back-end interoperability would create the infrastructure for users from one 
platform to interact with users on another; and delegability would give users the ability 
to delegate an external tool to interact with a platform for them. 


3.1. Competitive Compatibility 


We support a legal regime that will unlock and encourage competitive compatibility 
(ComCom): the ability of a competitor to interoperate with an incumbent’s products or 
services without permission. 


ComCom is absolutely essential for innovation. Overwhelmingly, the technologies we 


rely on today were not established as full-blown, standalone products; rather, they 
started as adjuncts to the incumbent technologies that they eventually grew to eclipse. 


ELECTRONIC FRONTIER FOUNDATION 12 





Privacy Without Monopoly: Data Protection and Interoperability 


The first cable TV service grew out of hobbyist efforts to bring big-city TV networks to 
their small-market towns. Modems were unsanctioned add-ons to Ma Bell’s ubiquitous 
copper phone lines. Before the Web, a tool called Gopher defied network operators’ 
intentions and made information from around the Internet accessible to the masses. 
Printers, ad-blockers, tape-deck audio jacks, and personal finance empires grew and 
thrived—not because anyone deliberately let them, but because nobody could stop them. 


We propose that users and companies should have the right to build around, and on top 
of, incumbent tools and services. Start-ups should have the right to engage with users 
on their competitors’ platforms, to chip away at the network effects that would keep 
them down. Users should have the right to engage with the platforms they use in any 
way they want, including through third-party tools that tune their experience. Nobody 
should receive a cease-and-desist for sharing a browser extension to improve a product 
they spend all day using. 


Unfortunately, some companies deploy a set of legal tools to undermine those rights and 
stave off small competitors, including the DMCA, CFAA, and Terms of Service and user 
agreements. 


The Digital Millennium Copyright Act (DMCA) is the 1998 law that overhauled 
copyright in the digital world. It contains ''anti-circumvention" provisions (section 
1201) that bar circumvention of access controls and copy controls. This can be, and 
frequently is, used to shut down those who would devise new uses for their devices and 
services. 


The Computer Fraud and Abuse Act (CEAA) is another law that has grown beyond its 
original purview, becoming a powerful way to restrict interoperation. The CFAA was 
intended to establish penalties for malicious hacking, but it’s been misused to target all 
kinds of much more benign activities, including the creation of add-on products that 
depend on interoperability. The law provides civil and criminal penalties for one who 
“intentionally accesses a computer without authorization or exceeds authorized 
access.” Overbroad interpretations of this clause attempt to equate compliance with the 
law to compliance with Terms of Service. This has given private companies across the 
country power to decide what is unlawful and who prosecutors can go after for alleged 
computer crimes. 


Even outside the context of the CFAA, Terms of Service (ToS) and their cousins, End 
User License Agreements (EULAs), can be used to limit interoperability. These 
contracts, associated with nearly every technology good or service on the market today, 
can be loaded with language forbidding reverse engineering and the use of add-on 
services that require interoperability. Manufacturers are unlikely to sue users who 
violate those terms, but they will enforce those terms against third-party interoperators 
who try to modify the customer experience. 


All of these legal constructs are in need of serious reform. In several cases, that reform 
can begin without changing the statutes themselves. 
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For example, the DMCA already has language to protect innovators —courts just need to 
interpret it better. The DMCA contains a permanent exemption that allows you to 
circumvent a technological protection measure if it's necessary to analyze software to 
achieve interoperability, as long as that's your sole purpose in circumventing. But EFF is 
not aware of any case in which this carve-out was successful. A more complete 
protection for interoperability would be for courts to interpret Section 1201 of the DMCA 
to require a nexus to copyright infringement. In other words, only those whose 
circumvention is done in service of infringement would be breaking the law, while those 
doing noninfringing things, like analyzing code to make interoperable technology, 
would be free to do so. 


The CFAA, too, can be better construed. A case now pending before the Supreme Court 
may help clarify that violating TOS is not a crime. In Van Buren v. United States, the 
Court will for the first time consider if the CFAA criminalizes access that simply violates 
the use restrictions or TOS that companies impose to control the use of their websites, 
apps, and computer systems. A broad array of organizations and trade associations, 
including EFF, have urged the Court to construe the CFAA to target only those who break 
into computer networks to sabotage them or steal sensitive data. If the Court does so, it 
will be a win for competition. 


EULAs and ToS are non-negotiated contracts — “take it or leave it” arrangements, also 
called contracts of adhesion. Those “contracts” often include surprising terms that strip 
users of fundamental speech rights, and enforcing those contracts the same way we do 
with freely negotiated deals leads to shocking results. Fortunately, the law provides 
multiple independent bases to rein in such abusive policy practices: the “reasonable 
expectations” doctrine, unconscionability, and public policy limits on their 
enforcement. With a series of good rulings, abusive or highly anticompetitive ToS may 
be eradicated as a matter of legal precedent. 


Outside the courtroom, we can and should promote ComCom by pressuring Congress to 
pass long-pending legislation to rebalance the CFAA and Section 1201 and bring them 
closer to their intended purpose. We can demand new federal legislation protecting 
digital first sale, and legislation at all levels protecting the right to repair. We can also 
ask our state representatives to declare that as a matter of public policy, their state 
favors contracts that support interoperability, just as some states reject noncompetitive 
employment contract terms. Each of these would help. 


Finally, in addition to reining in laws that block interoperability, governments at every 
level can take steps to actively encourage it. The Open Source Definition is a framework 
for software licensing, designed to maximize certainty for new market entrants who 
make interoperable products and services; government procurement rules could dictate 
that only open source-friendly vendors will be considered. Consent decrees arising from 
FTC or other enforcement actions (including lawsuits) can impose behavioral remedies 
on bad-behaving companies, barring them from taking action against interoperators or 
requiring them to open their licensing terms. Voluntary covenants in standards bodies, 
professional associations, or federations (such as academic or research consortia) can 
bind adherents to standards of fair play. All of these can be used to make dominant 
companies more hospitable to interoperability. 
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Example 1: Giving communities the tools for self-determination 


After years of Facebook selling its groups as resources for medical communities, those 
same communities have been victims of multiple serious defects in Facebook’s group 
privacy model. In one notable example, the membership of a closed Facebook group of 
cancer “previvors” who carried a gene for breast cancer was in fact more broadly 
visible to third parties and marketers, effectively outing all of its members. The 
collective action problem of shifting the entire group to a rival platform was so 
pernicious that it carries on to this day. 


Imagine if the group members had been able to use a community migration tool that 
set up a two-way, scrape-and-push link between a Diaspora pod and a Facebook 
group, appending messages with a footer that alerted users to the proportion of group 
members (or message volume) that had migrated off Facebook. Once a certain 
threshold was met (51%, 75%, etc), the Diaspora community could have automatically 
severed its link to Facebook. 


This could be accomplished with ComCom: the technical tools required are 
straightforward, and could be built on top of Facebook’s groups system. Such a 
measure allows partial connectivity between dominant platforms and new 
entrants—to keep hold of the vine they’re swinging on until they have a firm grip on 
the next one—and to gradually transition from a dominant platform to an upstart 
platform, lowering transaction costs and solving collective action problems. 
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3.2. Interoperability Mandates? 


The second part of our proposal is a new set of legislative and administrative mandates 
for specific flavors of interoperability. These mandates are designed to force platforms 
to open up key parts of their infrastructure to help alleviate the network effects that 
keep competitors from getting a foothold. 


Our proposals are based on the framework laid out in the ACCESS Act of 2019. Legislation 
is one possible tool for implementing these policies, though they may also be 
implemented by other means, such as consent decrees or voluntary covenants. We 
recommend that any new mandates define the behaviors that businesses must support, 
but not the specific ways they should do it. And while protecting innovation in general is 
important, regulators and lawmakers must be extremely careful not to hamper 
companies’ ability to react to new security vulnerabilities or privacy threats. 


We endorse new mandates in three areas: data portability, back-end interoperability, 
and delegability. Together, these give users the power to use platforms on their terms, 
and allow competitors to use incumbent platforms to launch new, innovative rivals. 


Back-end interoperability and delegability mandates are designed to tip the scales away 
from entrenched platforms and towards smaller competitors, so we recommend that, at 
least at first, these should only apply to the largest monopolists. On the other hand, 
portability is a tool for both interoperability and user empowerment, so it should apply 
to a much wider range of companies. 


3.2.1. Data portability 


The first and simplest new policy is a universal right of data portability. Users deserve to 
do what they want with their data, and should have a right to quickly, easily download or 
move the data that a platform has about them. Compared to the other ideas in this 
paper, data portability is a relatively easy policy lift: laws have already created partial or 
full data portability mandates in several jurisdictions. The General Data Protection 
Regulation (GDPR) and the California Consumer Privacy Act (CCPA) both include some 
form of data portability mandate; as a result, most companies that do business in either 
California or Europe already have portability processes in place. 


Portability is as much about user rights as it is about interoperability between 
businesses. Therefore, the scope of a portability mandate should be wide. Most 
companies that collect or process users’ data should be required to make that data 
portable. This should also be less of a technical lift than the other mandates we discuss 
below. 


‘By “mandates” here we refer to requirements that platforms take affirmative steps, 
where necessary, to ensure that users (and the companies that serve them) have these 
capabilities. We specifically are not, and indeed strongly discourage, mandates that 
require specific or similar specific steps for how such capabilities are to be achieved. 
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Although the central idea of portability mandates is simple to grasp—that users should 
be able to access their data in a useful, accessible form—companies have clashed with 
regulators over just what data should be portable. Incumbents have argued that some 
data implicating other users is too sensitive to allow for simple porting. Conveniently, 
that “too sensitive” data is often the same data, such as friends’ contact information, 
that is key to helping small competitors off the ground. 


Still, large platforms now generally agree that portability mandates are acceptable, even 
beneficial. Google, Microsoft, Facebook, and Twitter are among the founding partners of 
the Data Transfer Project, an attempt to develop secure standards for sending user data 
from one service to another. Last year, Facebook signaled support for the portability 
mandate proposed in the ACCESS Act, and requested that regulators tell companies 
exactly what they need to export. 


Who has a right to what data? And what should they have a right to do with it? Those 
questions are central to getting a portability mandate right. 


3.2.2. Back-end interoperability 


The second flavor of mandate is back-end interoperability, which has a much more 
extensive set of requirements. The goal of this kind of mandate is to allow users of small 
services to interact with users on big platforms. This gets directly at the network effects 
that make it so easy for Facebook and YouTube to shrug off competition. 


A back-end interoperability mandate would require platforms to allow competitors to 
work with their internal systems on behalf of users whose data lives elsewhere. The core 
principle of the mandate would be this: any service operated by the platform that allows 
users to communicate with each other—whether by direct message, public or 
semi-public posts, comments, or reactions—should allow users that are not signed up 
with the service to engage in those same kinds of communication. 


Think about what it would mean to interact with Facebook as a user of a similar, but 
distinct, social network. For full, meaningful interoperability, you’d need to be able to 
read, comment on, and react to content on Facebook in such a way that Facebook users 
can actually see it. You’d need Facebook to treat you in the same way that it treats its 
own users, but without controlling the authentication or data storage for your account. 
Broadly, this would require Facebook to create new connections in two directions: first, 
it would need to share data from its own users with third-party services; and second, it 
would need to ingest data from users of those outside services. (Example 2 explores this 
scenario further.) 
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Example 2: Federated social networking 


If we break Facebook’s monopoly power in social networking, what comes next? How 
would we go about breaking that monopoly power in the first place? The answer to 
both questions could be the same: a truly federated social network, in which users who 
have signed up for different services can interact with one another freely. To get there, 
Facebook would need to allow its users to become “friends” with accounts hosted on 
rival services. 


Facebook already has APIs that allows developers to access pretty much all data on 
behalf of a Facebook user. This lets developers build add-ons to Facebook’s core 
product, or glue between a user’s Facebook account and their account on another 
service. But it doesn’t allow developers to access data on behalf of users who are not 
on Facebook at all. 


To federate, Facebook would need to create an interface to allow Facebook users to 
become friends with off-platform identities. Facebook would have to explain to its 
users the kinds of data it will be sharing, and with whom. The user must trust at least 
two different actors: first, the administrator of the service they will be sharing data 
with, and second, whomever they are trying to connect with on that service. The user 
must also have an easy way to opt out of sharing data with either or both of those 
actors at any time. That means a way to “un-friend” the user on the other service, as 
well as a way to cut off the other service’s access to their data altogether. 


On the back end, Facebook would have to set up interfaces for bi-directional data flow 
between itself and third-party services. Its Graph API already provides (or has in the 
past) most of what’s needed for moving data out of Facebook: apps can already get 
programmatic access to a user’s posts, likes, photos, and basic profile information. 


The third-party service also needs a way to push data into Facebook. This means 
Facebook has to consume content from third-party users and distribute that content 
appropriately. It could accomplish this by letting outside services push updates that 
are shaped like Facebook data—posts, comments, and reactions—on behalf of their 
own users. Facebook could then display that content to its users in their regular feeds. 


Together, these pieces would change Facebook from a social media pocket universe, 
where users may only communicate with others inside the system, into a single part of 
aconstellation of social networks. People who are already invested in Facebook—that 
is, most of us—could try out new services without leaving all their old connections 
behind. 


All of this is unlikely to happen without outside incentive; it is simply not in 
Facebook’s interests to interoperate with potential competitors. It is more likely that 
Facebook will only adopt strong interoperability as a result of a legal mandate—or as 
part of a deal to avoid more dire consequences, like structural separation. Legal 
mandates—namely, for back-end interoperability—would need to outline what 
functionality Facebook needs to support, and govern how the company is allowed to 
moderate access to its new interfaces. 
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This kind of requirement may be burdensome to the companies that are subject to it. 
Therefore we recommend that, at least at first, these should only apply to dominant 
platforms that can afford the new costs of compliance. Furthermore, we recommend 
that policymakers stay away from being overly prescriptive wherever possible—as long 
as platforms build tools that make the desired data flows possible, and as long as there 
are appropriate safeguards for user privacy, it should not matter how they do it. This will 
leave room for future optimization and innovation. 


This kind of rule will be hard to do right, and will require ongoing monitoring. 
Regardless, it is worth doing. 


3.2.3. Delegability 


The third kind of mandate is delegability, or client-side interoperability. The concept is 
simple: anything you can do with a mouse or a touch screen to interact with a platform, 
you should be able to delegate to someone’s code to do on your behalf. Every substantial 
part of the user interface should be available to automated access. This means that a user 
could delegate a piece of software—either their own, or a trusted third-party tool—to 
interact with a platform on their behalf. These “delegated agents” will be able to tip the 
balance of power between users and platforms so that users come out on top. 


Delegability is closely related to ComCom. With a robust competitive compatibility 
regime, developers would be free to try to build on top of existing user interfaces. 
Delegability would take this to the next level, and guarantee that developers have stable, 
usable programmatic interface to act on behalf of users. 


Delegability is new to the tech sector, but it’s been pioneered in other industries through 
right-to-repair laws. Right-to-repair laws generally seek to mandate that 
manufacturers provide necessary repair and diagnostic information and parts to 
independent service providers and, sometimes, device owners. Some also go further, 
such as Massachusetts’ requirement that cars use a standardized interface for pulling 
diagnostics and communicating with on-board computers. Automotive right-to-repair 
laws have helped open up huge secondary markets for independent diagnostics, repair, 
and engine tuning. 


A delegability mandate can provide the benefits of client-side APIs without the risk of 
arbitrary moderation or sudden rollbacks that platforms have historically imposed. This 
kind of mandate could open space for a whole host of new user-friendly applications, 
from custom filters on social media feeds to new tools for accessibility, from audits of 
political ads to independent stewardship of privacy settings. This kind of mandate 
guarantees that platform interfaces will remain stable and accessible, making it more 
feasible for users and developers to invest in building on them. 
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Example 3: Third-party privacy controls 


Many sites offer relatively detailed privacy settings. Facebook has several different 
pages that control data collection, sharing, and use across a suite of (sometimes 
linked) products. And these settings’ defaults and options change over time, often 
without notice. Users generally do not want to think about every single setting; many 
would prefer to have the most privacy-preserving settings turned on by default. An 
“install-and-forget” privacy setting app would allow users to delegate an 
intermediary to make sure they are getting the most private experience possible over 
time. 


Competitive Compatibility would make this possible. A browser extension designed 
around the particular workings of platforms’ privacy pages could automatically load 
up the page, set the preferred check boxes and sliders, and warn the user when 
companies deploy dark patterns to get them to “opt back in.” 


In aComCom-based solution, tools would be fragile, and subject to Facebook’s 
decisions to fight them off. If the company wanted to fight with interoperators, it 
could deploy many of the same tools it does against ad-blockers and ad fraud 
networks. That would lead to a technical back-and-forth, with some tools able to stay 
ahead of Facebook’s maneuvering, and others breaking as they fall behind. Ina 
ComCom world (where Facebook no longer has legal remedies against interoperators) 
Facebook might arrive at an equilibrium where it offers privacy tools a managed 
access —or Facebook might decide to fight on, judging that the anger of users who are 
kicked off of Facebook for violating its terms of service is a price worth paying for 
continued dominance. 


Delegability would set in stone the right to outsource privacy decisions. A delegability 
mandate guarantees users a right to programmatically interoperate, and Facebook 
would defy users at its own legal peril. A privacy setting tool isn’t merely possible, it’s 
simple. It could be integrated into tracker blockers and even browsers themselves. 
Users could install a pan-platform privacy toolkit to keep them protected across all 
entities subject to the mandate. 


The obvious privacy risk with this kind of tool is that the delegated agent could turn 
out to be a bad steward of user privacy. But because the tool would be so easy to build, 
it could be volunteer-developed free software. Users could choose a tool from an actor 
they trust not to have ulterior motives. 
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4. Interoperability: Risks and Mitigations 


Both competitive compatibility and platform-sanctioned interoperability create privacy 
risks for users. ComCom applications are often villainized by the platforms, sometimes 
with good reason. Any third-party application that puts itself between a user and a user 
interface, like a screen-scraping financial data aggregator or a browser extension, can 
see everything that the user can see. And they do not always take good care of what they 
collect. Yodlee, a financial data aggregator in the vein of Mint, sells its data to hedge 
funds; some browser extensions have features that look a lot like spyware. 


The APIs that companies voluntarily expose are also abused, often dramatically. When 
Cambridge Analytica set out to build psychographic profiles on millions of voters, it was 
able to gather data from users and their friends without those friends’ consent. Internal 
documents reveal that while the collection occurred, Facebook executives were already 
considering curtaining the access they offered to apps like Cambridge Analytica’s 
thisisyourdigitallife. By the time the story broke, Facebook had long since shut down the 
offending APIs. But once the data got out, neither Facebook nor the users it exposed 
could do anything to bring it back. 


Users rarely have legal recourse when their privacy is violated by an interoperator (a 
problem we would like to solve by enacting comprehensive consumer data privacy 
legislation, including a private right of action). The platforms, in contrast, now have 
several courses of action. If the offending party is using a sanctioned API or distributing 
an app through a company store, the platform can simply remove their privileges. The 
platform can also change the way a product works, either to reduce the privileges that 
API users enjoy or to foil an adversarial interoperator. In some cases, they may go as far 
as to sue the offending third party using claims under CFAA or copyright law. 


In short: when interoperability happens, data gets shared, sometimes by design and 
sometimes in spite of it. When that data is misused, platforms may respond by removing 
the interoperability they choose to support or by using the law to shut it down. 


All of this happens against the backdrop of a United States that is sorely lacking in 
national consumer privacy law. If consumer privacy were properly protected, these 
issues would not be nearly so pressing. Without a privacy regime, policymakers in the 
tech space must more carefully consider the consequences that every new policy may 
have on user privacy. What protections do exist are often brittle, cobbled together from 
accidental shared interests, and reliant on the whims of monopolists. 


Change anything about the balance of power, some argue, and the whole system stands 
to collapse into chaos. This misses the point: it’s already chaos. Privacy in the digital 
world is not okay. We need to fix the system with laws that actually address the problem, 
directly and with conviction. And a huge part of the problem is monopoly. 
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4.1. Competitive Compatibility 


4.1.1. Risks of curtailing corporations’ legal weapons 


Currently, companies can use the DMCA, CFAA, contract law, and other legal theories to 
shut down ComCom interoperators. And large platforms sometimes use these theories to 
cut off access to actors that they say would violate user privacy. 


The pro-privacy argument against ComCom falls along two lines: 


1. Rational companies wield their exclusionary powers wisely: they act as proxies 
for their users’ interests, blocking privacy-invaders, fraudsters, and other bad 
actors. 

2. Legal rights to exclude are a cost-effective way to deter bad actors; one effective 
lawsuit brought by Facebook against Power Ventures chilled investment in the 
sector for a decade. To the extent that companies should exclude, legal tools are 
the best way to do so. 


Understanding these arguments is key to understanding why ComCom- positive policy 
could create new risks for users. It’s true that bad actors—like data brokers—are 
sometimes deterred by the legal instruments that we propose scaling back. However, the 
privacy issues that ComCom highlights are not inherent to the kinds of data sharing that 
ComCom will enable: they are results of the lack of adequate privacy protections in the 
United States. 


First up is the idea that large, dominant Internet companies act as good stewards of their 
users’ data. Market concentration and lax privacy and security regulation have created 
what Bruce Schneier calls “feudal security.” Users—whose lives are increasingly 
digitized —do not have a public system that safeguards their security and safety, even as 
the consequences of breaches become more severe. Left without democratic institutions 
to defend their interests, users throw their lot in with “feudal” seigneurs, lordly 
mega-corporations that defend all those who pledge their fealty and put down roots in 
their demesne. 


This system has real benefits to users, so long as their interests are coterminous with 
the interests of the companies they have entrusted: if you want to be defended against 
malicious apps, the iOS App Store will do a pretty good job of it. Of course, when your 
interests diverge from the company’s (if you’re a Uyghur hoping to have an effective 
VPN to use in China), then the seigneur’s priorities take precedence over yours, with 
undesirable (and even lethal) consequences. 


If anti-ComCom tools are removed, the argument goes, the seigneurs upon whose might 
many users depend will be weakened. 


The platforms do, indeed, shut down interoperability in order to protect their users. 
Often, a platform can moderate its services by simply revoking API keys or pulling apps 
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from an app store. In these cases, the platform doesn’t have to reach beyond its own 
walls, it just has to stop granting certain privileges. An affirmative right to ComCom 
generally won’t stop companies from tending their own gardens in this way. 


Platforms also do more than just moderate; they also expend design and engineering 
time to stop interoperators who don’t ask permission. Sometimes this is done with 
targeted technical countermeasures, as in the age-old battle between virus and 
antivirus. Windows Defender and other antivirus programs check executable files for 
characteristics of known malware. They attempt to prevent specific behaviors that are 
known to have caused problems in the past. Sometimes, developers try to lock down a 
product so that nobody can do anything the seller doesn’t intend, as Apple has done with 
nearly every part of its iOS ecosystem. 


For example, one of the most common ComCom activities is “scraping,” or 
automatically gathering data through a web interface. Scraping is used for constructive 
things all the time, from public-interest research to opening up new markets. But it’s 
also a favored tool of data brokers. The huge amount of data made public via social 
media can be gathered by anyone with an Internet connection and some scripts. 
Dystopian trailblazer Clearview AI built a database of three billion faceprints, which it 
uses to assist police identify suspects, by scraping photos from social media. 


Facebook is a frequent target of scraping, and uses the CFAA to fight it. Last year, the 
company filed a set of cases against companies that allegedly collected Facebook users’ 
data through browser extensions. According to Facebook, this kind of legal action is rare. 
In its press release, the company claimed their action “marked one of the the first times 
a social media company used a coordinated legal strategy across jurisdictions to enforce 
its Terms and protect its users.” 


Facebook’s statement, while true, is misleading. It’s a mistake to confine the history of 
anti-interoperability gambits to legal cases that actually reach a courtroom. Often, the 
mere possibility of a lawsuit is enough to scare away would-be data gatherers. 
Companies deploy technical countermeasures as a first line of defense, but may count on 
a legal backstop if the levees break. Likewise, would-be interoperators know they need 
to get past a firm’s technical restrictions, but they also know that doing so might only 
win them a date in court at the defendant’s table. 


Removing this legal backstop would fundamentally change the balance of power. It 
would create a space for both investments and unabashed, concerted, cooperative 
efforts to defeat technical countermeasures that incumbents prop up. It could tip the 
scales against the platforms, despite their budgets for technical expertise, and might 
usher in a new wave of follow-on innovation. 


Amore ComCom- positive legal regime would mean Facebook can’t bring CFAA charges 


against data brokers simply for scraping, or block extensions that collect Facebook user 
data. Is this an acceptable tradeoff? 
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4.1.2. Mitigating privacy and security risks 


First, companies are good custodians of their users’ privacy only to the extent that this 
is a profitable strategy. App store moderation can protect users from abuse, but as with 
Android’s ban on ad-blockers and iOS’s Chinese ban on VPNs, moderation can also 
undermine privacy. Google balances privacy protection with tracking-derived revenues, 
and Apple balances privacy protection with access to Chinese manufacturing and 
customers. 


The anti-ComCom laws we propose narrowing are designed to protect companies from 
hackers, copyright infringement, and other threats to their bottom line—and companies 
have no obligation to deploy lawyers on their users’ behalf. Monopolists have little 
incentive to engage in costly lawsuits against third-party privacy violators unless user 
outrage reaches a critical mass. As a result, companies have rarely used the laws we’re 
concerned with to defend users, unless they’ re also defending their own shareholders. 


Second, it’s worth reiterating that nothing about removing legal barriers to competitive 
compatibility will impose new restrictions on what technical countermeasures 
platforms can deploy in defense of their users. Companies that are subject to technical 
mandates may be required to work with competitors they would otherwise have blocked, 
but ComCom-related policy will not stop platforms from trying to out-engineer their 
rivals. 


Third, even when companies do want to sue to protect their users, they lack the right 
tools to do so. Privacy should be protected by privacy laws, not copyright law and CFAA. 
Even when companies want to do the right thing, lawsuits against bad actors can make 
bad law. Criminalizing Web scraping and ToS violations (which are not usually 
associated with more serious security breaches) does far more harm than good. We 
would do better to develop and implement targeted privacy protections, rather than 
perverting computer crime law far beyond its intended purpose. 


Finally, ComCom would create space for new, better privacy protections and tools. 
Platform seigneurs have historically done more harm than good for user privacy, and 
the few examples of monopolists’ interests aligning with their users’ are not enough to 
justify the status quo. In the absence of other changes to law, we believe that 
competitive compatibility will not lead to significant new privacy issues for users. On the 
contrary, it will license users and third parties to develop add-ons, like the privacy 
settings manager in Example 3, that modify services to be more privacy-preserving. And 
as discussed in Example 1, when a platform doesn’t live up to their promises, it could 
help users execute a coordinate exodus to a competitor. 


The ability of rival competitors (or co-ops, or tinkerers) to allow users to override these 
dominant actors’ choices creates the possibility of a dynamic, evolving market, where 
new products rise to the fore on the basis of quality, rather than inertia or lock-in. More 
importantly, it allows users whose privacy needs are not compatible with a 
manufacturer’s commercial priorities to bypass the manufacturer’s decisions. 
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In our analysis, the most significant privacy harm that could be exacerbated by these 
proposals is the collection of potentially sensitive data from publicly- available websites 
by data brokers and other snoops. This is a problem, but it’s only the tip of a massive, 
severely underregulated iceberg of an industry. Even when data brokers collect personal 
information from Facebook, the most significant privacy harm does not happen at the 
point of collection, it happens during the subsequent processing and exploitation of the 
data. We would do better to develop and implement targeted privacy protections, rather 
than perverting computer crime law far beyond its intended purpose. Relying on 
Facebook’s use of CFAA to regulate these actors is like hoping bank robbers get pulled 
over for speeding in their getaway car. 


Ultimately, ComCom represents a trade-off: users whose privacy interests are 
well-protected by vendors will find their defenders with fewer legal weapons and more 
dependent on technical ones. But the worst actors— deliberate criminals—already 
violate the law to get at user data, and so companies can’t be wholly dependent on the 
law in any event. Meanwhile, users whose privacy interests diverge from corporate 
platforms’ priorities will have new options to protect themselves. And, finally, the 
platforms themselves will face marketplace retaliation for abusing user privacy, because 
users will find it easier than ever to shop around for better privacy without having to 
sacrifice their enjoyment of bad privacy actors’ services. 


4.2. Interoperability Mandates 


Requiring platforms to share more data may appear to go against trends in both privacy 
law and platform development in the past few years. GDPR, CCPA, and other privacy 
laws have put new restrictions that target the movement of personal data between 
platforms. And over the past half-decade, Facebook, Twitter, and others have mostly 
restricted, not expanded, their public-facing APIs. In the long shadow of Facebook’s 
Cambridge Analytica scandal, it is reasonable to be suspicious of new pathways for user 
data. 


But that’s precisely why we need new rules of engagement: to counter the 
anticompetitive and privacy-invasive effects of personal data concentrating in a few 
hands, while ensuring that any data that is shared is bound by strong restrictions on 
minimization and consent. In this section, we discuss the new risks interoperability 
mandates pose to privacy and security, and how we can mitigate them. 


4.2.1. Data portability 


While portability is simpler to imagine and to implement than the other mandates we 
discuss, it still comes with risks. Furthermore, portability mandates apply to companies 
of all sizes, so the risks must be considered in the context of small startups and 
companies outside of the traditional tech sector. 


Security and privacy risks 


Unlike policies to facilitate competitive compatibility, portability mandates require 
businesses to intentionally create new channels for sharing data. In some cases, existing 
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portability laws also stipulate that portable data must be easy to access: that is, users 
should not have to go through a lengthy verification process in order to receive their 
data. But if it’s too easy—if a company doesn’t properly verify that a user is who they 
say they are—then it can be easy for thieves to get it, too. 


This has already proven to be an issue for companies implementing GDPR. Researchers 
have shown that many companies are too lax with their verification, making it easy for 
bad actors to access sensitive data that belongs to others. This is a real problem. 


Portability mandates could also create ways to access data that didn’t exist before. 
Generally, data portability mandates cause companies to create a single portal where all 
of a user’s data can be accessed at once. This, in turn, could create new targets for 
phishing or other kinds of credential theft. 


Finally, it may be difficult to determine which data is subject to access requests from 
which people. In the past, Facebook has claimed that it cannot simply allow users to 
download a portable version of their friends list (complete with email addresses and 
phone numbers, if public), because their friends might not want Facebook to share their 
contact information. As a result, it created separate settings for making one’s contact 
information searchable and viewable by friends, and for allowing one’s friends to 
download that information as part of a data export. It made the export setting opt-in. 
The good-faith argument for this practice is that allowing programmatic access to 
certain data introduces privacy risks that are distinct from allowing a user to read or 
search for that same data by hand. Of course, granting automated access to friends’ 
contact information would also be a direct threat to Facebook’s ability to prevent 
competitors from gaining a foothold. 


Mitigations 


Some risks of portability are exaggerated, and do not need specific mitigation. For 
example, the idea that access to specific data via portability is materially riskier than 
access via a GUI is misguided. If a user has rightful, consensual access to others’ 
data—whether or not it’s directly about themselves—they should be able to access it the 
way they want. If granting users the right to export data they can already access creates 
substantial privacy risks, perhaps that data shouldn’t be available to them in the first 
place. Letting a user “see” a piece of information but not “download” it is rarely an 
effective privacy control—but it is a stubborn roadblock to smooth data portability. 


More difficult is making sure that exported data goes where it should. Some companies, 
especially large ones, already have sophisticated means of identifying their users and 
sharing sensitive data with them. However, a portability rule applied to all companies 
that handle user data will include a lot of businesses that don’t currently have secure 
ways of identifying people. There’s no easy way to guarantee that a person exercising 
the right to portability is who they say they are, but thoughtful regulation can go a long 
way. The California Consumer Privacy Act required rulemaking about Californians’ new 
“right to know,” a version of a right to data portability. EFF submitted comments to the 
California Attorney General, recommending that the AG give specific guidance for 
companies in some situations, but leave leeway for corner cases, such as when a user 
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doesn’t have an account with a business and isn’t identified by a legal identifier. Obvious 
safeguards against bad corporate behavior should apply here too: for example, any 
information that a user shares for the sake of verifying themselves should only be used 
for that purpose. 


Auser should be able to exercise their right to portability, and doing so should be simple 
whenever possible. At the same time, businesses should have discretion to deny access 
when a user truly can’t be identified, especially if sensitive information is at stake. A 
regulatory body, in this case the California AG, has the ability to review cases where a 
user feels they’ve been denied their rights. 


This style of mandate gives businesses incentives on two sides. First, if a business is 
found to be willfully and unfairly denying a user’s right to port their data, it can suffer 
penalties. On the other hand, it can also be found liable if it recklessly shares a user’s 
information with the wrong person. The sum of these incentives means that businesses 
should want to do what is best for users: share their data when they ask, whenever that’s 
possible without excessive risk. 


4.2.2. Back-end interoperability and delegability 


Interoperability mandates for both the server-side (“back-end interoperability”) and 
the client-side (“delegability”) require large companies to open up new data flows to 
smaller interoperators. These pipelines should be able to achieve their objectives—of 
increasing competition, innovation, and user choice—without subjecting users to new 
risks or bolstering the surveillance business model. 


Security and privacy risks 


The security and privacy risks of back-end interoperability and delegability mandates 
fall into three categories: 


1. Data sharing and mining via new APIs; 
2. New opportunities for phishing and sock puppetry in a federated ecosystem; and 
3. More friction for platforms trying to maintain a secure system. 


The fact that new data will flow across company boundaries is not the only source of 
risk. We also need to consider the consequences of breaking up a centralized platform’s 
power via federation, and of introducing government oversight to a fast-moving 
industry where security matters. 


Data sharing and data mining 


As described in Example 2, in order to enable federation, Facebook would need to create 
anew Set of interfaces that allow competitors to jack in and connect users across the 
borders of the company. Services that use these will have access to very sensitive data 
about the people they are connecting and will need to be prepared to protect it. 


This type of interoperation will expose huge amounts of behavioral data on users. Of 
course, Facebook and many other platforms already do this through their APIs and ad 
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networks, though the platforms reserve the right to revoke any company’s access for 
nearly any reason. Interoperability mandates would take decisions about who gets 
access to what out of the platforms’ hands, to a degree. 


Without new legal safeguards to protect the privacy of user data, this kind of 
interoperable ecosystem could make Cambridge Analytica-style attacks more common. 
Smaller social media servers might try to build a business around passively profiling 
users of other services they federate with. Cambridge Analytica’s entree to Facebook 
data was through an app downloaded by just over a quarter of a million people, a paltry 
number in social media circles. Any federated server that hosted a similar number of 
users could have access to all the same information that the Cambridge Analytica app 
thisisyourdigitallife had, plus much more. 


Even when smaller services act honestly, interoperating can be difficult, and there is a 
risk that user data will be mishandled in the shuffle. Privacy settings for social networks 
like Facebook are more complex than “share” or “don’t share.” To match user 
expectations, platforms that federate with Facebook will need to respect those settings 
in all their subtleties. If they do not (or cannot) match those settings, it could lead to 
data being shared beyond what users anticipate and being used in ways they don’t 
expect. 


Delegability carries similar risks. Facebook’s first attempts at client-side interfaces, 
including parts of the infamous early Graph API, were also nightmares for privacy. The 
problem was not necessarily that third-party tools could access lots of user data; that’s 
a prerequisite for any user-level API. The problem was that users didn’t understand who 
was accessing what, and Facebook did not police what companies were doing with data 
after they got it. 


Web extensions are also an instructive example. They enable ComCom at the website 
level, but extensions are also built on powerful APIs that give direct access to the 
browser. These APIs can be used for good or ill. The WebExtension API powers some of 
the most innovative and user-positive tools on the Internet, from ad- and 
tracker-blockers to accessibility helpers to archivers to transparency tools. But it has 
also allowed hundreds of companies to harvest and sell sensitive information from 
unsuspecting users. We have explained elsewhere that Google’s Chrome browser cannot 
roll back most of the extension APIs that allow harm without also nerfing tracker 
blockers; there will be similar tensions with most other delegable interfaces one could 
imagine. 


Imagine an alternate Facebook Newsfeed plug-in that lets you set the rules for what 
content shows up on your feed and how. The plug-in will see everything you see, and 
potentially even more things—like metadata, or filtered content—that you cannot 
readily access. Any user who partners with a delegated agent will likely expose a lot of 
data to that agent or their code. But delegated agents will have access to data from many 
different users, not just the ones who choose to use their services. Sharing a post with 
“friends” will also mean sharing with “friends and their delegated agents.” 
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This problem is similar to the issue we explored with data portability above: the privacy 
risks that can arise from giving automated access to information that users already have 
“manual” access to. However, it’s one thing when portability a user has the power to 
download their own data; it’s another when delegability gives a third-party company 
proxy access to data from thousands. One user is unlikely to develop invasive profiles on 
their own friends, but a third-party delegate may want to use its users’ positions in a 
social network to do so. When thousands of Facebook users installed 
thisisyourdigitallife, the trojan horse app that gathered data from Cambridge 
Analytica’s psychographic profiling, it had access to the “likes” of each user’s friends. 
That alone was enough to kick off a huge privacy scandal, leading to the biggest fine in 
Federal Trade Commission history, Delegated agents will have access to everything, 
instantly and continuously. 


Ultimately, this kind of access is necessary for the dream of delegability to work. As a 
result, privacy issues will have to be addressed at the policy level, with new privacy laws 
and safeguards on new interfaces. We discuss these safeguards in depth in the next 
section. 


Phishing and sock puppetry 


Of course, not everyone works within the bounds of the law. A second risk is that these 
mandates could expand the attack surface for criminal enterprises and state actors who 
are not afraid to be unfair and deceptive. In theory, a bad actor could spin up a federated 
social media server (or compromise an existing one), create a legion of fake identities, 
and send “friend requests” to thousands of different users in a phishing expedition. Less 
dramatically, bad actors may learn that a part of the federated ecosystem —perhaps a 
single server with little funding or poor security practices —is more amenable to users 
who would present false fronts to the rest of the world, and use that service as a base for 
their bad-faith operations. This is similar to the way that phishers and law enforcement 
“sock puppets” already abuse social media, but a given platform would have less power 
to shut down users on other federated services. 


Security and vulnerability patching 


Finally, it’s worth giving special consideration to interoperable interfaces that require 
sophisticated security. For example, consider an interoperable, end-to-end encrypted 
messaging service. If we require the maintainer of such a service to present stable 
interfaces, and make it difficult for them to update or change those interfaces, it might 
become harder for them to keep their service secure. A poorly structured mandate could 
force companies to compromise or drag their feet on security, and this could undermine 
some of the progress made with end-to-end encrypted services in walled gardens. 


Mitigations 


Even with all of these risks, a well-crafted interoperability mandate should be a net 
benefit for privacy. Architects of new interoperability policy will have the opportunity to 
establish guardrails on the specific data-sharing pathways that policy creates. 
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Moreover, under the proposed regime, only a small number of large companies would be 
required to open up new sets of interfaces, which should be easier to monitor than an 
industry wide change. And where platforms’ incentives align with users’, such as in the 
battle against phishing and the continual quest for sound cryptography, the best 
approach may be to get out of the way. 


Preventing personal data abuse 


We need clear rules and protections to ensure that platform interfaces meet 
interoperability requirements while protecting the data that flows across those 
interfaces. This goes for both client-side interfaces (created for delegability) and 
back-end interfaces (for federation). Neither the platforms subject to new requirements 
nor the companies that interoperate with them should collect more data than necessary 
for the purposes of interoperability. Neither party should be allowed to monetize or 
exploit the data they collect for secondary purposes. And both parties should verify that 
they have a user’s informed consent before beginning to transfer personal data across 
such an interface. 


Two principles must guide privacy rules: minimization and consent. Together, they can 
help ensure user autonomy to control their own use of technology. 


First, privacy rules must require minimization of the processing of users’ data, including 
collection, retention, sharing, and use. Interoperability will require that platforms share 
lots of data, but companies that interoperate with regulated platforms must be barred 
from processing any more of a user’s data than is strictly necessary to give them what 
they asked for. The platforms themselves will define the interfaces, and their incentives 
should naturally be aligned towards user privacy: they won’t want to share any more 
data than they need to. Not so for third-party services which choose to federate via the 
newly created interfaces: these may be inclined to process as much data as they can, and 
be tempted to use data in ways users may not want. Thus, strong legal safeguards are 
needed to ensure that when a user decides to link up with a friend on a new service, their 
data is only used in ways they expect. 


Second, privacy rules must require informed opt-in consent. Users must be given a 
choice whether or not to start interacting with another platform, and must be able to 
withdraw consent at any time. At every stage, users must be made aware of what data 
they are sharing with whom, why that data must be shared, and what it will be used for. 
In the case of back-end interfaces, the platform should be responsible for informing a 
user and obtaining their actual, informed consent. In the case of client-side interfaces to 
satisfy delegability mandates, the companies that act as delegated agents should bear 
the burden of notice and consent, and be held responsible when they act badly. 


Both consent and minimization rules are necessary. Absent a minimization requirement, 
companies that profit from surveillance are skilled at deploying dark patterns to 
manufacture phony “consent.” Additionally, certain uses of data collected through these 
legally-mandated interfaces should be absolutely off-limits, such as selling it to third 
parties or monetizing it through targeted ads. 
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Absent a consent requirement, a minimization rule might not adequately reflect the 
interests of individual users either. There is no one-size-fits-all approach to privacy, 
and there will be situations in which users deserve to make choices about how their data 
are collected and processed. 


Once again, consider the fully federated social network from Example 2. When building 
back-end interfaces for federating its service, Facebook will need to make sure it shares 
only the content that users direct it to share. But once PII crosses that threshold, it’s up 
to the receiving service to handle that information properly. Social media users ina 
federated ecosystem will likely think about data sharing in terms of which people will 
have access to it—not which companies. When sending a text message, one does not 
usually think about which carrier will receive it or what they will do with it. And that is 
how it should be. 


That means services in a federated network must abide by a consistent set of policies 
with respect to data that is shared across their boundaries. Where the policies of two 
services clash, it should be the responsibility of the satellite service—the one which is 
choosing to federate with a regulated platform—to make sure it handles the data it 
receives from the platform in the right way. On the other side, a platform that does share 
its users’ data through such an interface must make sure federated partners have all the 
information they need to process personal information according to each user’s 
preferences. 


Addressing identity, phishing, and security 


As we discussed, back-end interoperability and federation may exacerbate extant 
classes of attacks on user privacy, like phishing or sock puppetry. One way to mitigate 
this danger is with more stringent identity verification, so that users anywhere in the 
federated social media ecosystem can have confidence that they know who they are 
talking to. However, identity verification is a privacy issue of its own. Facebook is 
notorious for its intrusive and harmful “real names” or “authentic names” policy. 
Modern data brokers make millions in the identity verification business, hawking 
location, behavioral data, and other personal information so that businesses can be sure 
a customer is who they say they are. 


Interoperability brings this tension between verification and anonymity to the fore, but 
doesn’t necessarily worsen it. In a world where users can interact with each other across 
services, they should be able to make an informed choice about whether to trust a 
message from a Facebook-verified “authentic name” or a user identified by email 
address on a small, volunteer-run server. In fact, one of the biggest benefits of a 
federated social networking ecosystem will be that users who have been unfairly banned 
by Facebook, or who have simply chosen to abstain, can get in touch with their friends 
and family who do use the platform. 


Simple design choices, like asking a user to accept an invitation to a conversation before 
they can receive unsolicited messages, go a long way towards mitigating phishing and 
spam. It is also worth noting that social media platforms currently have incentives to 
encourage as many connections between their users as possible, and are constantly 
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suggesting new “friends” or “‘connections;” reducing those incentives might lead the 
platforms to develop user interfaces that are not so bent on proliferating network 
connections. Expertise and tools to detect malicious communications, which were 
largely either bought up or developed in-house by the larger platforms in the last 
decade, could instead find other customers as a more general third-party service for 
end-users or a market of smaller interoperable competitors. 


Adding it all together: Law, code, and competition 


The large platforms that are subject to new interoperability requirements will need to be 
held accountable: they should not be allowed to pass off subpar services, or unfairly 
deny access to competitors by invoking the language of user protection, But policy 
architects should let platforms decide how to engineer their systems to meet these 
requirements. 


Despite the flaws in the feudal privacy system, nobody is more qualified to make 
judgments about security threats than the platforms themselves, and platforms must be 
nimble to address emergent threats to their systems’ integrity. Some third-party 
services may prove to be bad actors, either misusing user data or neglecting to maintain 
secure systems, and large platforms should be able to cut off access to these legitimate 
threats. 


Navigating this tension—between the platforms’ undeniable technical expertise and 
knowledge about their own systems and their anti-competitive incentives —is key to 
making the whole thing work. Policymakers must try to realign the incentives of big 
platforms to match those of their users. It’s profitable to undercut competitors, so there 
must be large enough penalties for anti-competitive mischief to negate those profits. 
There also must be sufficient transparency so that it is possible to uncover that mischief. 
Likewise, penalties for violating user privacy, through negligence or intent, must be 
severe enough to offset the money that companies stand to make by doing so. And if a 
company violates a user’s privacy rights, then the user should have a private right of 
action so they can sue the company. 
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5. Conclusion 


The problems of corporate concentration and privacy on the Internet are inextricably 
linked. We believe that a new regime of interoperability can revitalize competition, 
encourage innovation, and give users more self-determination in their digital lives. It’s 
natural to imagine that new, legally-protected or legally-mandated data flows will lead 
to new privacy and security risks. But as we’ve shown, those risks are not as grave as 
they might first appear, and they can be mitigated. A more interoperable Internet can 
and should be a more private one. 


New interoperability mandates will create new data flows, and will take some discretion 
out of the hands of the platforms. Facebook and Google may be forced to share personal 
information with companies they wouldn’t have before. But mandates can come with 
strings attached, in the form of legal obligations for informed consent and data 
minimization. As a result, data that flows across these new interfaces may be more 
legally protected than any data that the platforms have chosen to share in the past. 


Creating more space for competitive compatibility will free tinkerers, startups, and 
nonprofits to interact with big platforms in ways that the platforms might not approve 
of—or might not have imagined. Will removing tools incumbents use to shut down 
ComCom hinder the platforms’ ability to protect their users? We do not believe so. It’s 
true that companies can sometimes use non-privacy laws to shield their users from 
legitimate privacy threats. But these legal tools have never been properly calibrated to 
protect users. 


In general, objections to interoperability presume that the companies who hold user 
data are best positioned to protect it. This is sometimes the case, but too often, the 
incentives of a platform and its users do not align. In the past, companies have often 
chosen to interoperate in ways that make them money at the expense of 
privacy—consider the ad tech ecosystem, in which millions of websites and apps 
interoperate with Google, Facebook, Amazon, and other ad platforms, swapping 
personal data and screen real estate for fractions of a penny per impression. The same 
companies have also refused to interoperate in ways their users might want when 
interoperation would mean sacrificing a competitive advantage. Clearly, when 
companies decide whether to share data, user welfare is not always the first concern. 


More than anything, the dangers of data-sharing that we have addressed here underline 
the need for better privacy law. In a world where user consent and purpose minimization 
are properly defined and vigorously protected, most of the concerns with new 
interoperability programs would be moot. More importantly, the idea that we must rely 
on platforms’ good will for our protection would seem rightfully absurd. EFF will 
continue to fight for better privacy laws. Towards that end, we believe interoperability 
and other pro-competitive policies are critical to breaking the platforms’ plutocratic 
influence over lawmakers. And we believe a more interoperable Internet will be more 
innovative, less concentrated, and more amenable to user rights. 
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